Content-MD5
header to be provided with the request.
It was especially challenging when combined with E2E encryption, as this rendered the: "Chicken or the egg" dilemma, where we had to provide MD5
before sending any data, however when we encrypt data we auto-send it in chunks to not cause any memory issues.
The solution was to implement Multipart Upload. It's a native S3 feature where file is uploaded in chunks.
This allowed us to overcome any memory-hungry operations and divided upload of big files on a smaller manageable chunks.
The positive side-effect is that if your file upload fails, when you retry file it will start from the last failure point (currently only works without encryption enabled).
Finally, improving the encryption scheme allowed us to build decryption proxy, so we can convert the Rclone encrypted blob into video stream that's understandable by video players.
That's how encrypted videos playout was implemented. It was deployed experimentally to all platforms.
We didn't manage to build decryption proxy for Web and even if we did, the performance would be terrible (https://github.com/rclone/rclone/issues/7192), so we're temporarily hosting the proxy in our infrastructure. Since it poses some privacy risks, we've implemented BIG WARNING to the user.
We've also implemented ZIP download for multiple selected files and delivered lots of bugfixes and performance improvements as usual. (edited)